峰值|容忍度_如何做压测？

篇首语：本文由编程笔记#小编为大家整理，主要介绍了如何做压测？相关的知识，希望对你有一定的参考价值。

简介&＃xff1a;压测的一般流程和方法是什么&＃xff1f;需要关注哪些数据指标&＃xff1f;如何推算后端需要支持的qps&＃xff1f;本文分享总结压测过程中需要注意的问题&＃xff0c;希望对同学们有所启发&＃xff0c;欢迎讨论~

一 压测目标

在开始做压测计划之前&＃xff0c;一定要先明确压测的目标是什么&＃xff0c;虽然最终的目标肯定都是优化系统的性能&＃xff0c;但是不同的出发点&＃xff0c;可能需要采取不同的方法。

一般来说&＃xff0c;可能有以下一些目的&＃xff1a;

1 挖掘系统瓶颈点&＃xff0c;优化系统性能

尤其对新系统上线&＃xff0c;缺乏性能基线数据&＃xff0c;此时压测一般没有明确的qps/rt等指标&＃xff0c;而是通过不断施压&＃xff0c;不断逼近系统的极限&＃xff0c;从而暴露问题&＃xff0c;修复问题。

2 建立性能基线

主要是为了收集系统当前的最大性能指标&＃xff0c;一般会根据业务特点&＃xff0c;先确定对rt和错误率的容忍度&＃xff0c;然后通过压测推算出能够支持的最大qps, 并发量等。

同时可以结合性能指标和监控数据&＃xff0c;来建立合理的预警机制&＃xff0c;设立系统水位报警项&＃xff0c;限流阈值&＃xff0c;弹性策略等。

量化系统能力/SLA等 &＃xff08;比如在竞标中引用&＃xff09;。

3 性能回归

对于已上线系统&＃xff0c;或者性能需求明确的系统&＃xff0c;可以根据线上实际的运行情况&＃xff0c;确定系统需要支撑的qps/rt, 然后在涉及性能影响前做回归校验&＃xff0c;确保性能满足预期。

4 系统稳定性

更侧重在一定压力的情况下&＃xff0c;系统是否能长时间稳定持续的提供SLA保障。

一般可以考虑将压力设定到业务峰值的80%&＃xff0c;持续施压。

5 网络/线路延迟稳定性等

在一些特殊的业务场合&＃xff0c;对延迟的容忍度极小&＃xff0c;比如DNS解析&＃xff0c;CDN服务&＃xff0c;多人实时在线游戏&＃xff0c;高频交易等等&＃xff0c;需要网络质量&＃xff0c;尤其是不同线路&＃xff08;电信/联通/教育网/...&＃xff09;间的差异。

二 压测对象

明确了压测目标后 &＃xff0c;就是确定要压什么&＃xff0c;来实现目标。

一般来说&＃xff0c;压测对象可以这么分&＃xff1a;

• 后端
• 
  
  • 单api
• 
  
  • 单业务逻辑场景
• 前端
• 
  
  • 单request
• 
  
  • 单操作
• 
  
  • 单页
• 
  
  • 整体页面平均情况

三 压测数据

压测过程中&＃xff0c;一般主要关注一下数据指标&＃xff1a;

1 starter/client

最重要的三个指标&＃xff1a;

• qps
• rt
• 成功率

其他的&＃xff1a;

• 页面平均响应时间 &＃xff08;重要&＃xff09;。
• 并发量&＃xff08;其实没那么重要&＃xff0c;主要还是qps&＃xff09;。
• 最大用户同时在线数 &＃xff08;用户登录系统&＃xff0c;一般不需要额外压测&＃xff0c;除非业务场景特殊&＃xff09;。
• 网络质量&＃xff08;延迟&＃xff0c;波动等&＃xff0c;不展开&＃xff09;。

2 server

主要是监控数据&＃xff1a;

• cpu usage
• load
• mem
• jvm/fullGC
• 连接数(netstat)
• disk io (iostat / iotop)

四 压测结果分析

一般是随着压力的增加&＃xff08;并发请求的增加&＃xff09;探究qps/rt/成功率三者的关系&＃xff0c;从而找到系统的平衡点&＃xff0c;如果能结合服务端的监控数据&＃xff0c;就更好。

五 压测工具

1 jmeter

concurrent Thread Group

java sampler

composite chart

可以将多个chart组合到一个chart中&＃xff0c;并且坐标系会自动伸缩&＃xff0c;方便在一个图中展示结果。

六 性能指标推算方法

以上都是一些系统向的指标数据&＃xff0c;其实对用户来说是不感知&＃xff0c;或者说也是没有意义的。那什么样的数字是有意义的呢&＃xff1f;举个例子&＃xff1a;

如果你提供的是一个在线的网页服务&＃xff0c;那用户可能关心的是&＃xff0c;你的系统在保证不察觉卡顿的情况下&＃xff08;系统的SLA&＃xff0c; 实际可能容忍存在偶发的页面错误重试&＃xff09;能承受多少人并发使用。

如果你提供的是个结算系统&＃xff0c;那用户可能关心的是&＃xff0c;在保证交易有效性的情况下&＃xff08;不能出错&＃xff0c;但是可以偶发超时重试&＃xff0c;同样是系统的SLA&＃xff09;&＃xff0c;每秒可以处理多少笔订单。

举例分析&＃xff1a;

1 基本算法

此处pv表意不清&＃xff0c;实为后端日志统计的后端api的调用次数&＃xff0c;如果有前端统计的一般意义上的pv(page visit)&＃xff0c;基本原理相同&＃xff0c;可以简单换算一下&＃xff0c;pv * x-ratio &＃61; 后端调用次数。

1. 获取现场每日asapi PV/UV的均值/峰值。
2. 取Max&＃xff08;PV峰值*0.8&＃xff0c;每日PV均值&＃xff09;作为目标PV&＃39;&＃xff0c; PV&＃39;时段的UV值作为实际并发用户参考值N&＃39;&＃xff0c; 计算PV&＃39;/perMinute/N&＃39;作为每分钟用户操作触发api次数O&＃39;。
3. 根据以下规则换算成后端需要支持的qps&＃xff1a;

• 3.1 模型假设&＃xff1a;2/8原则——每日有80%的PV发生在20%的工作时间内&＃xff08;ratio&＃61;0.8&＃xff09;。
• 3.2 假设页面单个请求映射到后端api请求比例为1:10&＃xff0c;假设一天working hour为8小时 (e&＃61;10)。
• 3.3 假设一般用户&＃xff0c;高峰期每分钟操作页面10次 &＃xff08;o&＃61;10&＃xff09;。
• 3.4 根据现场日PV计算支持N&＃39;用户并发操作需要的qps&＃xff1a;PV&＃39; * ratio/(working hour∗60∗60∗(1−ratio) )&＃61; qps
• 3.5 根据现场峰值小时级PV计算支持N&＃39;用户并发操作需要的qps&＃xff1a;PV&＃39; * ratio/(1∗60∗60∗(1−ratio) ) &＃61; qps

1. 根据压测qps推算能够支持的最大用户同时使用数&＃xff1a;

• 4.1 同样基于上述公式&＃xff0c;根据上述假设&＃xff0c;1分钟内&＃xff0c;每个用户操作10次&＃xff0c;每次前端操作对应后端10个api&＃xff1a;
• 
  
  • 1分钟PV &＃61; N 10 10
• 
  
  • N 10 10 / 60 &＃61; qps &＃61;&＃61;> N &＃61; qps * 0.6
• 4.2 如果按照小时为单位推算&＃xff0c;1个小时内&＃xff0c;每个用户操作页面100次&＃xff0c;每次前端操作对应后端10个api&＃xff1a;
• 
  
  • 60分钟PV &＃61; N 100 10
• 
  
  • N 100 10 / 6060 &＃61; qps &＃61;&＃61;> N &＃61; qps 3.6

2 正向推演

如果现场环境数据表明&＃xff0c;高峰期9:00~10:00有50人登录过系统&＃xff0c;pv累计10000&＃xff0c;那么根据&＃xff08;3.1&＃xff09;&＃xff0c;系统整体qps >&＃61; 11&＃43; 才能维持当前用户量正常使用。

3 反向推演

如果家里环境压测结果表明&＃xff0c;随机API调用qps&＃61;30&＃xff0c; 保持上述假设&＃xff0c;参照&＃xff08;4.2&＃xff09;&＃xff0c;即可支撑18人高峰期同时操作。

4 不严谨的地方

上述算法针对随机API按照1:1计算&＃xff0c;实际上调用肯定是不均匀的&＃xff0c;可以根据现场的数据统计下api的调用分布&＃xff0c;压测是模拟相同的调用分布尽量贴近实际。

另外用户每分钟操作页面次数&＃xff0c;和每次前端请求对应后端api的膨胀比都是预估出来的&＃xff0c;虽然可以根据模型做近似&＃xff0c;但是不如直接根据现场数据计算出来准确。

七 其他考量

• 链路跟踪能力&＃xff0c;分析瓶颈点
• 
  
  • api log
• 
  
  • eagleye-traceId

• 缓存对数据库的影响
• 
  
  • 是否需要压到db层&＃xff0c;要考虑压测场景。

• 
  
  • 是否需要创造海量的随机压测数据 &＃xff08;比如针对单用户的缓存优化场景&＃xff0c;单一用户的性能不能用来推送多用户并发的场景&＃xff09;。
• 同步接口异步接口的压测 &＃xff08;staragent&＃xff09;
• 
  
  • 主要考验后台任务处理能力&＃xff08;异步任务提交即时返回了&＃xff09;。
• 系统不同层次的限流设置对API的影响
• 
  
  • 比如有业务层的限流如Sentinel, nginx层的限流如X5, 或者其他基于LVS的限流等。
• 消息通信&＃xff0c;尤其是广播消息。
• 数据库&＃xff0c;尤其是写一致性。
• 复杂场景的长链路调用。
• Nginx/Tomcat的配置对请求的影响。
• 容易忽视的对象序列化/反序列化对性能的影响。
• 热点数据。

原文链接&＃xff1a;https://developer.aliyun.com/article/779380?

版权声明&＃xff1a;本文内容由阿里云实名注册用户自发贡献&＃xff0c;版权归原作者所有&＃xff0c;阿里云开发者社区不拥有其著作权&＃xff0c;亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容&＃xff0c;填写侵权投诉表单进行举报&＃xff0c;一经查实&＃xff0c;本社区将立刻删除涉嫌侵权内容。